home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_0799 / 564 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  2.2 KB
  1. Subject: Re: pipes & ptys
  2. Date: Wed, 20 Oct 93 19:04:42 CET
  3. From: Juergen Lock <nox@jelal.north.de>
  4. In-Reply-To: <9310191343.AA02341@pirol.techfak.uni-bielefeld.de>; from "itschere@TechFak.Uni-Bielefeld.DE" at Oct 19, 93 2:43 pm
  5. Message-Id: <9310201804.AA00159@jelal.north.de>
  6.  
  7. itschere@TechFak.Uni-Bielefeld.DE writes:
  8. > Howard Chu <hyc@hanauma.jpl.nasa.gov> writes:
  9. > 
  10. > > A simple shell would just use cooked mode and read a line at a time, not
  11. > > single-character, btw...
  12. > 
  13. > Maybe the shell, but not my imaginary window manager. If it waits for each
  14. > newline, screen output will look pretty poor... :-(
  15. > 
  16. > > Just a note to TeSche - the 1 byte I/Os are converted to 4 bytes to allow
  17. > > pty's to pass scan code and shift status info, just like Bconin from console.
  18. > 
  19. > Looking at the code, I discovered that recently. Point is that it - more or
  20. > less - doesn't matter if my 1000 1 byte fread calls get expanded to 100 4 bytes
  21. > fread calls. It looks like waiting with fselect(m,0,0,0) (thanks Eric!) and
  22. > than read all that is there with one fread call is the best idea at the
  23. > moment. I'll look at it, but for now I presume finstat() really reports the
  24. > number of bytes in a pipe.
  25.  
  26.  yes but you don't need it, since the read() is RAW it will tell you how
  27. much data it got.
  28.  
  29. >  So at least my reading program will not be the
  30. > bottleneck, if the writing one choses to write in 1 byte chunks, I loose...
  31.  
  32.  not you if you usleep (or Fselect(m,0,0,0)) before the read...
  33.  
  34. >  ... So you won't need an extra system call, but just a new device
  35. > driver for the biosfs...
  36.  
  37.  hmm looks i was not clear enough again :)  that was exactly my point 4...
  38. > 
  39. > Perhaps I'll start playing with this idea in some future, it's just that I
  40. > expect great difficulties with existing programs, since they MUSTN'T use the
  41. > bcon*() calls any more... :-(
  42.  
  43.  well if you dup2() the new device to the programs' /dev/aux...  but
  44. since Bcon* still is single-char IO programs that use it will still
  45. be big CPU time eaters so you might want to get rid of them anyway. :-)
  46. > 
  47. > bye,
  48. > TeSche
  49.  cheers
  50.     Juergen
  51. -- 
  52. J"urgen Lock / nox@jelal.north.de / UUCP: ..!uunet!unido!uniol!jelal!nox
  53.                                 ...ohne Gewehr
  54. PGP public key fingerprint =  8A 18 58 54 03 7B FC 12  1F 8B 63 C7 19 27 CF DA 
  55.